System and method of network diagnosis

ABSTRACT

Embodiments provide systems and methods for diagnosing a network and identifying problems in a network which reduce the data transfer rate of data through the network. One embodiment of a method for network diagnosis may include infusing data into a network upstream and downstream of a portion of the network relative to a library drive, querying the drive at intervals over time for drive data to determine the data transfer rate at the drive and comparing the data transfer rate of the data infused upstream of the device or network portion with the data transfer rate of the data infused downstream of the device or network portion to determine throughput. By comparing the data transfer rate of data infused upstream and downstream of a network device or network portion, problem devices in a network may be identified.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of, and claims a benefit of priorityunder 35 U.S.C. 120 of the filing date of U.S. patent application Ser.No. 14/144,077 filed Dec. 30, 2013, entitled “SYSTEM AND METHOD OFNETWORK DIAGNOSIS”, by inventor Robert C. Sims, which is a continuationof, and claims a benefit of priority under 35 U.S.C. 120 of the filingdate of U.S. patent application Ser. No. 13/091,877, filed Apr. 21,2011, entitled “SYSTEM AND METHOD OF NETWORK DIAGNOSIS”, by inventorRobert C. Sims, issued as U.S. Pat. No. 8,644,185, on Feb. 4, 2014,which is a continuation of, and claims a benefit of priority under 35U.S.C. 120 of the filing date of U.S. patent application Ser. No.12/025,322, filed Feb. 4, 2008, entitled “SYSTEM AND METHOD OF NETWORKDIAGNOSIS”, by inventor Robert C. Sims, issued as U.S. Pat. No.7,974,215 on Jul. 5, 2011, the entire contents of which are herebyexpressly incorporated by reference for all purposes.

TECHNICAL FIELD

This disclosure describes systems and methods of network diagnosis. Moreparticularly, embodiments of methods and systems regard infusing data atknown locations to diagnose network performance. In one embodiment, theperformance of devices in the network and the data transfer rate throughnetwork devices can be determined such that the performance of devicesin the context of a network can be diagnosed.

BACKGROUND

Networks can be comprised of a multiplicity of network devices such asservers, routers, hosts, switches, repeaters, hubs, encryption devicesand backup devices such as media libraries.

In many systems, data may be sent over a network from multiple hosts onthe network to a library for storage. Such hosts may include computers,servers or other devices. In many instances, the data is routed to thelibrary through a multiplicity of network devices which may include oneor more switches, routers, servers, hubs, encryption devices or othernetwork devices. A host or other device may also request data from alibrary and this data may be routed to the host or other device throughthe network.

One example of a library commonly used for data storage is a magnetictape library. A magnetic tape library can comprise components such astape cartridges (containing magnetic tape), robots, tape slots and tapedrives. A typical magnetic tape library contains multiple cartridgeslots in which tape cartridges can be stored. Tape cartridges, commonlyreferred to as tapes, are physically moved between cartridge slots andtape drives by a robot. The robot is controlled by commands receivedfrom the host devices on the network. When data is to be written to orread from the library, a host device determines which cartridge slotcontains the tape cartridge that is to be written to or read from. Thehost device then transmits a move-element command to the robot and therobot moves the tape cartridge to a tape drive which reads the desireddata from the tape cartridge.

A tape drive in a library reads from or writes to magnetic tapecontained in a cartridge utilizing a sensor which may comprise a readhead and a write head. In one embodiment of a drive, magnetic tape ispulled past the sensor comprising the read head and the write head suchthat the read head can read data from the tape and the write head canwrite data to the tape.

Reading and writing to a cartridge inherently causes the degradation ofthe tape comprising the cartridge because the tape is pulled past theread and write heads. Pulling the tape past the read and write heads maystrain the tape and the tape may collide with the read or the writeheads at read or write speed. Especially deleterious to tape life isstarving a drive of data to write to a tape. In particular, if data isreceived at a drive at below the drive's ability to write data (i.e. atbelow the drive's streaming rate), then the movement of magnetic tapemay have to be slowed or reversed in order to write data with thenecessary density, wearing the tape. Such back and forth pulling of tapepast the read and write heads of a drive is referred to as“shoe-shining” and has the potential to accelerate tape degradation.Consequently, bottlenecks or other decreases in data transfer ratescaused by network devices can have a deleterious effect at the library.

SUMMARY

Embodiments provide systems and methods for network diagnosis and theidentification of problem devices in a network or other issues. A systemfor network diagnosis can include a library comprising a drive, anetwork coupled to the drive and operable to transmit data to the drive,an infusion device coupled to the network upstream of a portion of thenetwork relative to the drive and operable to infuse control data intothe network and a monitoring appliance coupled to the network andoperable to send commands to the drive over the network, wherein themonitoring appliance is further operable to calculate the data transferrate at the drive based on drive data returned in response to thecommands. In some embodiments, two or more infusion devices may becoupled to the network, each infusion device upstream or downstream of anetwork portion. In embodiments of a system for network diagnosis, themonitoring appliance can communicate with the infusion device(s) overthe network to cause the infusion device(s) to begin infusing data intothe network.

Embodiments of methods and systems for network diagnosis can include amethod comprising infusing control data into a network coupled to adrive at known location(s) upstream and downstream of a portion of thenetwork relative to the drive, querying the drive at intervals over timefor drive data by sending one or more Log Sense (LS) commands or Inquirycommands to the drive and determining the data transfer rates at thedrive for data infused upstream and downstream of the portion of thenetwork based on returned drive data.

Embodiments of methods and systems for network diagnosis can include oneor more computer readable media comprising computer instructionsexecutable to perform the above method. Such computer readable media maybe contained in a monitoring appliance or an infusion device.

By diagnosing a network and identifying problem devices or other issueswhich reduce throughput through the network or otherwise reduce the datatransfer rate of data through the network, networks problems can bediscovered and addressed, improving throughput through the network andpreventing network devices from reducing the data transfer rate.Furthermore, because issues which reduce the data transfer rate througha network are resolved, data transfer rates which cause the starving ofdata to a drive of a library and the consequent shoe-shining of magnetictape in cartridges being written to by the drive may be avoided,extending the life and enhancing the reliability of magnetic tapecartridges.

BRIEF DESCRIPTION OF THE FIGURES

A more complete understanding of embodiments of methods and systems andthe advantages thereof may be acquired by referring to the followingdescription, taken in conjunction with the accompanying drawings inwhich like reference numbers indicate like features and wherein:

FIG. 1 is a diagrammatic representation of one embodiment of a library;

FIG. 2 is a diagrammatic representation of one embodiment of a network;

FIG. 3 is a diagrammatic representation of one embodiment of a network;

FIG. 4 is a flowchart illustrating a method for collecting and compilingnetwork device data;

FIG. 5 is an XML representation of an example of data returned inresponse to a LS command;

FIG. 6 is one example of a graphical user interface; and

FIG. 7 is a diagrammatic representation of one embodiment of acontroller which can be used in a monitoring appliance.

DESCRIPTION

Embodiments are illustrated in the FIGURES, like numerals being used torefer to like and corresponding parts of the various drawings.

As used herein, the terms “comprises,” “comprising,” “includes,”“including,” “has,” “having” or any other variation thereof, areintended to cover a non-exclusive inclusion. For example, a process,process, article, or apparatus that comprises a list of elements is notnecessarily limited only those elements but may include other elementsnot expressly listed or inherent to such process, process, article, orapparatus. Further, unless expressly stated to the contrary, “or” refersto an inclusive or and not to an exclusive or. For example, a conditionA or B is satisfied by any one of the following: A is true (or present)and B is false (or not present), A is false (or not present) and B istrue (or present), and both A and B are true (or present).

Additionally, any examples or illustrations given herein are not to beregarded in any way as restrictions on, limits to, or expressdefinitions of, any term or terms with which they are utilized. Insteadthese examples or illustrations are to be regarded as being describedwith respect to one particular embodiment and as illustrative only.Those of ordinary skill in the art will appreciate that any term orterms with which these examples or illustrations are utilized willencompass other embodiments which may or may not be given therewith orelsewhere in the specification and all such embodiments are intended tobe included within the scope of that term or terms. Language designatingsuch nonlimiting examples and illustrations includes, but is not limitedto: “for example,” “for instance,” “e.g.,” “in one embodiment.”

This disclosure describes systems and methods for diagnosing networks.Embodiments of systems and methods may be used to diagnose networks suchthat bottlenecks, inefficiencies or problem devices in the network canbe identified. Data sent over a network to be stored in magnetic tapesat a library may encounter bottlenecks, inefficiencies or problemdevices in the network which may slow the transmission of the data orreduce the data transfer rate (which can be expressed in MB/s) to thelibrary, reducing the amount of data received by a library drive tobelow a library drive's streaming rate. Starving a drive of data in sucha manner can cause the movement of magnetic tape being written to by adrive to be slowed or reversed in order to write data with the necessarydensity, wearing the tape in a so-called shoe-shine fashion. Similarly,data sent from a drive to a host or other device over a network may alsoencounter bottlenecks or problem devices.

To detect bottlenecks, inefficiencies or problem devices in a networkthat reduce the data transfer rate to a drive to below the drive'sstreaming rate, data may be artificially infused into a network at knownlocations upstream or downstream of specified devices or networkportions and the data transfer rate of the infused data at a drive maybe monitored. For example, known data may be artificially infusedupstream of an encryption appliance utilizing an infusion device and thedata transfer rate of the artificially infused data may be monitored ata library drive utilizing a monitoring appliance which may be a ReadVerify Appliance (RVA). Known data may also be artificially infuseddownstream of the encryption appliance utilizing another or the sameinfusion device and the data transfer rate of the artificially infuseddata may be monitored at a library drive utilizing the monitoringappliance. If the monitoring appliance detects that the data transferrate of the data infused upstream of the encryption appliance is slowerat a library drive than data infused downstream of the encryptionappliance, it may be determined that the encryption appliance is actingas a bottleneck, lowering the data transfer rate, reducing thethroughput of the network and perhaps contributing to starving one ormore drives in a network of data.

Similarly, data may be requested from a specific drive of a library attwo or more known locations in a network and the difference in the datatransfer rates of data sent to different locations from the drive may bemonitored at the drive utilizing the monitoring device. Differences inthe data transfer rates may be used to determine problem network devicesor portions of the network which act as a bottleneck.

FIG. 1 is a diagrammatic representation of one embodiment of a tapelibrary, as would be understood by one of ordinary skill in the art.Library 100 can comprise drives 140 a-140 e, media changer 125 andassociated robot 130, import/export element(s) 145 and slots 135 a-135j. Drives 140 a-140 e can read/write data from/to magnetic tape(contained within cartridges), eject tape cartridges and perform otheroperations. Slots 135 a-135 j store the magnetic tape cartridges whenthey are not in a drive and robot 130 moves the magnetic tape cartridgesbetween drives 140 a-140 e and slots 135 a-135 j. For example, robot 130may move a tape cartridge stored at slot 135 a to drive 140 b so thatdata can be read from the tape cartridge. It should be noted that somelibraries may employ a single robot or multiple robots in an expandableor modular configuration.

To collect data associated with a library or library components such as,for example, drives, a monitoring appliance can query a library orlibrary components over a network utilizing commands. In response toreceived commands, the library or library drives may return dataassociated with a particular command to the monitoring appliance. In oneembodiment, a monitoring appliance can query a library drive over anetwork utilizing SCSI commands such as the Log Sense Command, InquiryCommand and other commands.

A Log Sense (LS) command is a command which is used to obtain dataassociated with a particular drive. A LS command is sent to a particulardrive of a library and in response, the drive returns data associatedwith media contained in the drive. For example, such data might include:utilization and performance data such as, for example, data transferrates, media loaded, the amount of data received by the drive, theamount of data sent or transmitted by the drive, the amount of datawritten by the drive, the amount of data read by the drive or otherdata. In one embodiment, the drive returns the current count of bytestransferred since a cartridge was loaded. Examples of a LS command canbe found in “SCSI Primary Commands-3 (SPC-3)”, (Project T10/1416-D),Revision 22a, Mar. 25, 2005, propagated by the T10 Technical Committeeof the InterNational Committee on Information Technology Standards(INCITS), which is hereby incorporated by reference.

An Inquiry command is a command that is used to query the serial numberof components of a library such as a drive or a media changer.Embodiments of Inquiry commands query individual library components.That is, an individual Inquiry command may query a particular drive forits serial number. Examples of an Inquiry command can be found in “SCSIPrimary Commands-3 (SPC-3)”, (Project T10/1416-D), Revision 22a, Mar.25, 2005, propagated by the T10 Technical Committee of the InterNationalCommittee on Information Technology Standards (INCITS), referencedabove.

Methods and systems for collecting data from a library or library drivecan utilize a monitoring appliance which can be a Read Verify Appliance(RVA). The monitoring appliance queries a library or drives by sendingLS, Inquiry commands and/or other commands to the library or librarycomponents at intervals. Data returned in response to the commands maybe used to determine the data transfer rate of data to (or from) a driveand whether the data transfer rate is below the drive's streaming rate,causing shoe-shining. It should be noted that determining the datatransfer rate of data may comprise one or more calculations. Datareturned in response to the commands may be saved to a repository andinformation or data calculated from returned data (for example, the datatransfer rate at the drive) may also be saved to the repository. Forexample, a LS command may be sent to a drive periodically, such as, forexample, every 30 seconds, such that when data is being received by adrive from the network and written to magnetic tape, the amount of datareceived by the drive within the period between LS commands may bereturned to the monitoring appliance in response to the LS commands.This returned data specifying the amount of data received at the drivemay be used to determine the data transfer rate at which the drivereceives data or the rate at which the drive writes data to magnetictape. Based on the data transfer rate, it can be determined whether thedrive is receiving data at a desired data transfer rate, above thestreaming rate of the drive or below the streaming rate of the drive.Similarly, LS commands can be used to determine the data transfer rateof data sent over a network from a drive.

To write data to media contained in a drive of a library or read datafrom media contained in a drive of a library, thereby infusing data intoa network, a device such as an infusion device located at a knownlocation in a network can send commands to one or more library drives.In one embodiment, the commands used to infuse data into a network maybe Write commands or Read commands.

A Write command is a command which can be used to transfer data tospecified drives and write data to tape cartridges (or other librarymedia such as laser discs, hard drives or any other media). That is, adevice, which may be an infusion device, sends a Write command which maycontain data to a drive and in response, the drive writes the datacontained in that Write command to a cartridge. Thus a Write command canbe used to send data to a drive over a network or portion thereof.Examples of a Write command can be found in “SCSI Block Commands-3(SBC-3)”, (Project T10/1799-D), Revision 6, 24 Jul. 2006, propagated bythe T10 Technical Committee of the InterNational Committee onInformation Technology Standards (INCITS), which is hereby incorporatedby reference.

A Read command is a command which can be used to read tape cartridges(or other library media such as laser discs, hard drives or any othermedia). That is, a requesting device-which may in one embodiment be aninfusion device-sends a Read command to a specified drive and inresponse, the drive reads data stored on the cartridge and the read datais returned to the requesting device. Thus a Read command can be used toretrieve data from a tape cartridge in a drive and transmit theretrieved data over a network or portion thereof. Examples of a Readcommand can be found in “SCSI Block Commands-3 (SBC-3)”, (ProjectT10/1799-D), Revision 6, 24 Jul. 2006, propagated by the T10 TechnicalCommittee of the InterNational Committee on Information TechnologyStandards (INCITS), which is hereby incorporated by reference.

Methods and systems for sending data over a network to a drive caninclude sending multiple Write commands to a specified drive from aknown location in a network utilizing a device which may be an infusiondevice. The infusion device may be connected to the network at the knownlocation and may send a Write command to the specified drive. Inresponse to receiving the Write command or processing the Write command(for example, by writing data contained in the Write command to media),the specified drive may return an indication such as a command completemessage to the infusion device, in response to which the infusion devicesends another Write command. The above process may be repeated multipletimes such that data is infused into the network at a known location andsent to the specified drive at a data transfer rate supported by thenetwork portion downstream of the known location of the infusion deviceand upstream of the library drive.

Methods and systems for sending data over a network from a drive caninclude sending multiple Read commands to a specified drive from a knownlocation in a network utilizing a device which may be an infusiondevice. The infusion device may be connected to the network at the knownlocation and may send a Read command to the specified drive. In responseto receiving the Read command and processing the Read command (forexample, by reading data from media), the specified drive may returnread data to the infusion device, in response to which the infusiondevice sends another Read command. The above process may be repeatedmultiple times such that data is infused into the network and sent to aknown location from the specified drive at a data transfer ratesupported by the network portion downstream of the known location of theinfusion device and upstream of the library drive.

FIG. 2 is a diagrammatic representation of one embodiment of a system200. In system 200, hosts 290 a and 290 b, which may be personalcomputers, and library 100 are coupled to network 210 such that hosts290 a and 290 b may send data over network 210 to a drive at library100, namely drive 140 a. In FIG. 2, network 210 may be a fibre channelnetwork, IP network or any other network or combination of networks.Network 210 can comprise network devices such as switch 220, router 230,hub 240, repeater 250, server 260, encryption device 270 or othernetwork devices. Data sent from hosts 290 a and 290 b over network 210to be stored at library 100 may traverse a path which includes anynumber of network devices, including switch 220, router 230, hub 240,repeater 250, server 260 or encryption device 270, alone or incombination. One or more network devices comprising network 210,including network devices 220-270, may slow the transfer of data fromhosts 290 a or 290 b to library 100, thus reducing the data transferrate to drives in library 100, potentially starving the drives of data,causing drives to receive data at or below a streaming rate. Networkdevices may slow the transfer of data to library 100 because they arenot properly configured, because they are not working properly, becausethey are poorly-performing devices or any one of a number of otherreasons.

FIG. 3 is an embodiment of a system operable to artificially infuse datainto a network such that the network can be diagnosed and problemnetwork devices or other issues identified. System 300 of FIG. 3comprises infusion devices 330 and monitoring appliance 320, all ofwhich are coupled to network 210. Monitoring appliance 320 is coupled tonetwork 210 such that monitoring appliance 320 can send commands to andreceive data from the devices comprising library 100 (for example, drive140 a) over network 210. In response to the commands, monitoringappliance 320 can receive information that allows monitoring appliance320 to determine the data transfer rate of data received at (or sentfrom) library 100. By infusing data with infusion device(s) 330 at knownlocations and known data transfer rates, and evaluating the datareceived from library 100, the location and magnitude of bottlenecks andother inefficiencies can be determined.

As an initial example, inefficiencies caused by encryption device 270can be identified. In network 210, encryption device 270 encrypts datasent over network 210 to drive 140 a of library 100. Encryption device270 receives data destined for drive 140 a and encrypts the data beforetransmitting the encrypted data to drive 140 a. Drive 140 a receives theencrypted data and writes the encrypted data to magnetic tape. If drive140 a receives the encrypted data at or below its streaming rate, themagnetic tape may have to be slowed or reversed while writing in orderto write data with the necessary density.

To determine the performance of encryption device 270, infusion devices330 may be coupled to network 210. Infusion device 330 a is coupled tonetwork 210 upstream of encryption device 270 such that infusion device330 a is operable to infuse known data, such as, for example, data witha known compressibility, known data sequences or with other knownparameters, into network 210 such that the infused data traverses anetwork path including encryption device 270 before the infused datareaches drive 140 a. During processing of the infused data (which may,in one embodiment, comprise writing the data to tape) at drive 140 a,monitoring appliance 320 can query the amount of data received at drive140 a over time by sending LS commands over network 210 to drive 140 a,in response to which drive 140 a returns the amount of data received,the amount of data written, the speed at which data was written or otherdata. Based on the returned amount of data received, the monitoringappliance can determine the data transfer rate at the drive and thus thedata transfer rate (i.e. throughput) through encryption device 270.

Infusion device 330 b is coupled to network 210 downstream of encryptiondevice 270 such that infusion device 330 b is operable to infuse knowndata (for example, data with a known compressibility, known datasequences or with other known parameters) into network 210 such that theinfused data traverses a network path which does not include encryptiondevice 270. During processing of the infused data (which may, in oneembodiment, comprise writing the data to tape) at drive 140 a,monitoring appliance 320 can query the amount of data received at drive140 a over time by sending LS commands over network 210 to drive 140 a,in response to which drive 140 a returns the amount of data received,the amount of data written, the speed at which data was written or otherdata. Based on the returned amount of data received, the monitoringappliance can determine the data transfer rate at the drive and thus thedata transfer rate (i.e. throughput) through network 210 downstream ofencryption device 270.

In one embodiment, to determine the data transfer rate of infused data,multiple LS commands may be sent to a drive at a predetermined frequencywhile the drive is writing the artificially infused data to tape. Thedata returned may include the amount of data transferred to the driveover the network in the interim between the last LS command, thus thedata transfer rate at the drive can be calculated by dividing the amountof data (which may be in MB) received by the drive over the networkbetween LS commands by the duration between the LS commands (which maybe in seconds).

The differential between the data transfer rates of data infused byinfusion device 330 a and data infused by infusion device 330 b (i.e.the difference in throughput) can be used to diagnose whether encryptiondevice 270 acts as a bottleneck or otherwise hinders the transmission ofdata to drive 140 a over network 210. For example, if encryption device270 encrypts data at below a certain rate and is consequently not ableto transfer data at an adequate data transfer rate to drive 140 a, drive140 a may be starved of data. Thus, to detect such an issue or problemor similar issues or problems, data may be infused upstream ofencryption device 270 by infusion device 330 a, if the data transferrate of the data infused by infusion device 330 a is lower than the datatransfer rate of the data infused by infusion device 330 b, thanencryption device 270 may be acting as a bottleneck and reducingthroughput through the network.

In another example, infusion devices 330 a and 330 b may send Readcommands to drive 140 a over network 210. Monitoring appliance 320 canuse LS commands to determine the data transfer rates of data sent fromdrive 140 a to infusion devices 330 a and 330 b: if the data transferrate is higher at infusion device 330 b than 330 a, encryption device270 may be acting as a bottleneck and reducing throughput through thenetwork.

In one embodiment, monitoring appliance 320 can communicate withinfusion devices 330 over network 210 to turn on or off data infusionfrom infusion device 330 a or infusion device 330 b into network 210.Monitoring appliance 320 may also select the data to be infused intonetwork 210, for example, non-compressible data or compressible datehaving a known compression ratio. It may also be possible to activateinfusion devices 330 utilizing a host which sends commands to infusiondevices 330 over network 210. Monitoring appliance 320 may be notifiedover network 210 that an infusion device 330 has been activated and isinfusing data into network 210. Monitoring appliance 320 may synchronizewith an infusion device 330 through communications with the infusiondevice 330 over network 210. In another embodiment, infusion device(s)330 may be manually activated. In another embodiment, an infusion devicemay have multiple connections and each of the multiple connections maybe coupled to different known locations in the network. Thus, theinfusion device may be able to infuse data at multiple points in thenetwork. For example, the infusion device may have one connectionupstream of encryption device 270 and another connection downstream ofencryption device 270. In a still further embodiment, monitoringappliance may include an infusion device or an infusion device modulewhich may be connected to one or more known location in a network,allowing the monitoring appliance to diagnose the network.

While in FIG. 3, a single pair of infusion devices are shown, multipleinfusion devices may be utilized in a network to diagnose differentdevices or sections of a network. For example, in FIG. 3, an additionalinfusion device may be located upstream of hub 240 and infusion device330 a. If data from the additional infusion device is received at adrive at a lower data transfer rate than data infused by infusion device330 a, this implies that the network portion downstream of theadditional infusion device but upstream of infusion device 330 a islimiting throughput, acting as a bottleneck and consequently reducingthe data transfer rate. Thus, multiple infusion devices may be used inconjunction to diagnose a network for problem devices. Multiple networkdevices in a network may reduce throughput, the use of multiple infusiondevices or moving an infusion device to multiple locations in a networkmay allow the degree to which individual network devices reducethroughput to be determined. Depending on the data transfer rates ofdata received from particular infusion devices and the locations of theinfusion devices, the source of network bottlenecks can be inferred.

Infusion devices may be operable to infuse different sets of known datawith different properties. For example, such sets of known data mayinclude data sets of different compression ratios. In one embodiment, amonitoring appliance can send one or more commands to an infusion deviceto select a particular set of data to infuse into a network. Sets ofdata sent from an infusion device may contain data allowing the data tobe correlated with the infusion device that infused the data.Furthermore, infusion devices may be portable devices which may beremoved and coupled to different locations in a network to diagnosedifferent devices or network sections.

FIG. 4 is a flow chart illustrating a method 410 for identifying networkbottlenecks or other network or network device issues. According to oneembodiment, one or more steps of method 410 can be implemented as a setof computer executable instructions stored on computer readable mediaat, for example, monitoring appliance 320 and infusion device 330 ofFIG. 3. The set of computer executable instructions can, when executed,be utilized to identify network bottlenecks. At step 420, known datadestined for a known drive is infused upstream of a known device ornetwork section. For example, 2:1 compressible data may be infused intoa network upstream of an encryption device. At step 430, the drivereceiving the data infused at step 420 may be queried at known intervalsto determine the amount of data transferred to a drive betweenintervals. At step 440, the data transfer rate of the known data at thedrive is determined. For example, LS commands may be sent to the driveevery 30 seconds and the amount of data received at the drive in a 30second interval divided by 30 seconds to determine the data transferrate to the drive.

At step 450, known data destined for a known drive is infused downstreamof a known device or network section. For example, 2:1 compressible datamay be infused into a network downstream of an encryption device. Atstep 460, the drive receiving the data infused at step 450 may bequeried at known intervals to determine the amount of data transferredto a drive between intervals. At step 470, the data transfer rate of theknown data at the drive is determined. For example, LS commands may besent to the drive every 30 seconds and the amount of data received atthe drive in a 30 second interval divided by 30 seconds to determine thedata transfer rate to the drive.

At step 480, the data transfer rate of data infused upstream of theknown device or network section (determined at step 440) is compared tothe data transfer rate of data infused downstream of the known device ornetwork section (determined at step 470). If the data transfer rates arethe same (or within some acceptable difference), then the device ornetwork section is functioning correctly or not overly decreasingthroughput. If, however, the data transfer rate of data infused upstreamof the device or network section is lower than the data transfer rate ofdata infused downstream of the device or network section, the device ornetwork section is reducing throughput and acting as a bottleneck to thetransfer of data. Thus, problem devices may be identified and the degreeto which problem devices reduce throughput can be determined. Method 410or one or more steps of method 410 may be repeated to diagnose multipledevices or sections comprising a network to identify throughput lossesand device performance issues throughout the network.

While method 410 of FIG. 4 regards sending data to a drive, in otherembodiments, data can be sent from a drive and received at knownlocations in a network. The data transfer rates of data receivedupstream and downstream of network devices or network portions can becompared to identify problem devices or problem network portions and thecorresponding reduction in throughput.

In one embodiment, a monitoring appliance can compile data returned inresponse to LS or Inquiry commands in defined structures (which may be,in one embodiment, XML structures or other structures). A structure maycontain data associated with a library component returned in response toone or more commands (which may be, in one embodiment, LS or Inquirycommands). For example, a XML structure can include the amount of datareceived by (or sent from) a drive at a point in time from a LS commandand the unique serial number of the drive determined from an Inquirycommand issued to the drive. Such structures may be contained in arepository and compared such that data transfer rates can be determinedfor a drive. For example, a structure associated with a point in timemay be compared with a structure associated with a subsequent point intime. The difference between the amount of data received by (or sentfrom) a drive can be determined through a comparison of the twostructures and based on the difference in time between the twostructures, an approximate data transfer rate for a point in time can bedetermined.

FIG. 5 is an XML representation of an example of data returned inresponse to a LS command. The data may include the amount of datareceived by a drive at a point in time. For example, MB read 510 is theamount of data received by a drive at a point in time. Data returned inresponse to LS commands sent at different times may include the amountsof data received by a drive at different times. The difference in theamounts of data received by a drive at two points in time may be dividedby the duration between the two points in time to determine the datatransfer rate at the drive at an approximate point in time.

Based on the determined data transfer rate at the drive, it can beascertained whether the drive is being starved of data and whether andto what extent shoe-shining is occurring. Furthermore, because the datatransfer rate is monitored over continuous intervals of time, datatransfer rates over time can be stored (for example, in a repository),giving a user (virtual or otherwise) a relatively accurate data transferrate history over time. For example, when the data transfer rate isdetermined over periodic 30 second intervals, the data transfer rate atthe drive is up-to-date on at least a 30 second interval. Thus, thecurrent data transfer rate may be presented to a user or a data transferrate history may be presented to a user utilizing a user interface. Inone embodiment, a graph of the data transfer rate over time may bepresented to a user utilizing a user interface.

FIG. 6 is one example of a graphical user interface displaying agraphical representation 600 of the data transfer rate at a drive overtime. Data transfer rate 610 is the data transfer rate of data receivedby a drive. Graphical representation 600 includes streaming rateindicator threshold line 620, which indicates the streaming level of thedrive. Graphical representation 600 also includes ideal data transferrate indicator line 630, which indicates the ideal data transfer ratefor the drive and maximum data transfer rate indicator line 640, whichindicates the maximum data transfer rate for the drive. Data transferrate 610 can be compared with lines 620, 630 and 640 by a user viewinggraphical representation 600. In one embodiment, data transfer rate 610may graph the data transfer rate of data infused into a network by aninfusion device at a known location.

FIG. 7 is a diagrammatic representation of a monitoring appliancecontroller 700 (“controller 700”). Controller 700 can include aprocessor 702, such as an Intel Pentium 4 based processor (Intel andPentium are trademarks of Intel Corporation of Santa Clara, Calif.), aprimary memory 703 (which may be, for example, RAM, ROM, Flash Memory,EEPROM or other computer readable medium known in the art) and asecondary memory 704 (which may be, for example, a hard drive, diskdrive, optical drive or other computer readable medium known in theart). A memory controller 707 can control access to secondary memory704. Controller 700 can comprise a communications interface 706 (whichmay be, for example, fibre channel interface, Ethernet port or othercommunications interface known in the art) to connect controller 700 toa network (for example, network 110 of FIG. 2). An I/O controller 712can control interactions with the network. Similarly, an I/O controller714 can control interactions over I/O interfaces 708 and 710. Controller700 can include a variety of input devices. Various components ofcontroller 700 can be connected by a bus 726.

Secondary memory 704 can store a variety of computer instructions thatinclude, for example, an operating system such as a Windows or Linuxoperating system (Windows is a trademark of Redmond, Wash. basedMicrosoft Corporation) and applications that run on the operatingsystem, along with a variety of data. More particularly, secondarymemory 704 can store a software program 730 that interfaces with devices(which may be, for example, drives or infusion devices) over a networkand determines the data transfer rate at one or more drives. Duringexecution by processor 702, portions of program 730 can be stored insecondary memory 704 and/or primary memory 703.

While systems and methods have been described with reference toparticular embodiments, it should be understood that the embodiments areillustrative and that the scope of the invention is not limited to theseembodiments. For example, while systems and methods disclosed above aredescribed with regard to a physical library, further embodiments ofsystems and methods described above may be used in the context ofvirtual tape libraries, optical jukeboxes, archive systems such as MAIDsystems or other archive systems and other mass storage systems using avariety of storage media. Many variations, modifications, additions andimprovements to the embodiments described above are possible. It iscontemplated that these variations, modifications, additions andimprovements fall within the scope of the invention as detailed in thefollowing claims.

What is claimed is:
 1. A computer program product comprising one or morenon-transitory computer readable media embodying computer executableinstructions implementing a method for network diagnosis, comprising:sending a command to an infusion device to initiate infusing of controldata by the infusion device; periodically sending commands to a drive ofa media library over the network while the control data is beingtransferred at the drive to collect data generated by the drive;receiving responses to the commands from the drive, the responsesspecifying amounts of data; and determining a measure of networkperformance for a portion of the network between the infusion device anddrive based on the responses from the drive.
 2. The computer programproduct of claim 1, wherein the measure of network performance comprisesan actual data transfer rate at the drive.
 3. The computer programproduct of claim 2, the method further comprising comparing the actualdata transfer rate to a desired data transfer rate.
 4. The computerprogram product of claim 2, wherein the actual data transfer ratecomprises a rate at which drive received the control data.
 5. Thecomputer program product of claim 2, wherein the actual data transferrate comprises a rate at which the drive wrote the control data.
 6. Thecomputer program product of claim 1, wherein the commands sent to thedrive comprise SCSI commands.